In conventional mobile communication networks in particular in a core network overload maybe experienced in the control plane. For example many users may simultaneously initiate attached request procedures or service request procedures with their user devices resulting in overload. Overload in the user plane may occur for example due to an unexpected situation or concentrated heavy user activity. Such a heavy user activity may for example a massive high definition video streaming service, the download of big files or the like. Further in addition to such normal user devices there may be a number of machine type communication MTC devices deployed in the same cells of a base station of a mobile communication network together with normal user devices, i.e. non-MTC user devices, which are frequently or infrequently transmitting data on their own or based on a trigger request from a machine type communication application server.
When the mobile communication network is running into overload in a certain node or entity of the network then the device trigger requests for MTC devices scheduled at the time of the overload by the MTC application server would increase the already present overload. Already ongoing data transfers of machine type communication devices being in active mode are handled by conventional congestion handling defined in 3GPP TR 23.705. However a machine type communication device in idle mode should not become active during the present of an overload situation. This is possible, since machine type communication devices are different from normal user devices since their triggering is flexible to a substantial degree in contrast to normal user devices which a user would like to initiate multimedia sessions or the like.
In FIG. 1 shows a time relationship between a device trigger and a following active data transfer period. When a device trigger is received by the corresponding user device UD a time gap TG occurs resulting from processing time, state transfer from the mode IDLE to the mode ACTIVE and potentially a back-off timer in case of an overload for example in the mobility management entity MME until the user device UD has changed to mode ACTIVE and congestion is handled with conventional user plane congestion handling UPCON. The user device UD is therefore not immediately transmitting data after it received a device trigger DT.
In FIG. 2 the situation of user plane congestion and its relation to congestion handling of MTC device triggers is shown. In the upper half of FIG. 2 the number of trigger requests DT for machine type communication user devices UD, which are in idle mode, are shown and in the lower part the data traffic of user devices UD in active mode is shown during and around a congestion period which end time points t1 and t4 mark this period.
In FIG. 2 it is further assumed that two levels of congestion, namely a light and a civil congestion, exist: When a light congestion starts at time point t1 a triggering of machine type communication user devices which are currently in idle mode are be reduced in order to not to allow substantial data traffic to be generated in the upcoming period. In the depicted case of FIG. 2 the mobile communication system runs into severe congestion at time point t2 after which machine type communication device triggers are further reduced. With abatement of the overload situation at time points t3 and t4 respectively reverse handling is performed.
Overload or congestion management in the user plane may take place in parallel if radio access network user plane congestion and detection mechanisms.
FIG. 3 shows a scenario of current device triggers DT when a certain evolved node B eNB experiences an overload in the user plane—user plane congestion—or when a mobility management entity MME experiences a signaling overload in the control plane CP—control plane congestion—. In 3GPP TR 23.887 it is disclosed that the machine type communication interworking function machine type communication interworking function MTC-IWF supports a load control functionality to indicate the service capability servers SCS over the Tsp interface to limit trigger loads generated on said interface.
Further it is disclosed how the mobility management entity MME, the serving GPRS support node SGSN/the short message service center SMS-SC and the machine type communication-interworking function machine type communication interworking function MTC-IWF provides overload control functionality to allow the mobility management entity MME, the serving GPRS support node SGSN or the short message service center SMS-SC to limit trigger loads generated over the T5b, T5a and/or T4 interface. The information which the mobility management entity MME or the serving GPRS support node SGSM can send in an appropriate message over the T5b/T5a interface with optional information elements indicating only T5 suppression parameters like suppression factor, suppression duration or suppression subcategories, for example a specific priority type or the like.
However, the above mentioned conventional technique has inter alia the disadvantage that only a general indication to the service capability server SCS in particular in case of MTC user devices can be given that there is an overload situation. Thus all machine type communication user devices in the whole network are affected although a network overload may only specific to one or a very limited number of nodes.